COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	Dear Lick:
C00013 ENDMK
C⊗;
Dear Lick:

	This letter concerns three related subjects: the present hardware
and software situation of the Stanford AI Lab, the general problem of
uniformity and diversity in hardware and software, the need for continued
research into time-sharing per se.

	1. Our situation is based on our history.  I think we were the first
lab to be equipped by ARPA with a PDP-6; the M.I.T. AI PDP-6
was a originally a gift from D.E.C..
At the time we started, we solicited proposals from
a number of manufacturers and received responsive proposals from IBM and D.E.C.,
although the IBM proposal would have required us to write our own time-sharing
system for a 360/50.  Since that time, our hardware has grown by accretion
and so has our system software.  We have thrown nothing away and have added
a PDP-10 processor, a full house of memory, and an IBM 3330 disk system.
The result of all this is a more complicated hardware situation than
that of the labs that started with PDP-10s or started with SDS940s and
later scrapped them for PDP-10s.

	Our PDP-10 accomodates more users than any other on the ARPA net.
This is partly because the original swapping disk we got in 1967 still has
a higher transfer rate than any other in use on the net,
partly because we have stuck with a basically simple
system not using paging, and partly because
we haven't felt like or been encouraged in asking for a second system.  The unique
characteristic of our present system is its emphasis on displays of which we
have 70.  The time-sharing system is heavily display oriented, and there
is a desire to go even farther in that direction in a new system.

	Our system programming staff consists of three people, Ralph Gorin,
Jeff Rubin, and Brian Harvey and has always been about that size.  This compares
with about five professional programmers working on projects and even more
students.  My impression is that this number of programmers is not too far
different from the number employed by non-BBN TENEX places that nominally
get their system programming from elsewhere.

	We cannot stay where we are at least without refusing D.E.C.s offer
of a free KL-10 processor.  We badly need the increased power of the KL-10,
because straight computing power is now the resource in shortest supply
as was determined by the length of the various queues in the time-sharing
system and the complaints of the users.  However, we also need more memory,
and our present system cannot address more.  Moreover, we want to be able
to use Interlisp, and this requires paging as does the installation of more
memory.

	2. Possible ways we can go.

	a. The simplest course would be to accept the KL-10 and supplement
it by having ARPA by us a complete new set of hardware, swappping disk,
512K of D.E.C. core, file disks, terminal controllers, and
about 3 PDP11s and with interfaces to the KL-10.  I haven't priced this
option, but I would imagine it would cost between $600,000 and $800,000.
Then we would have a completely standard system, especially if D.E.C.
allowed us to put our display oriented system features in their system.

	b. For us to go to a TENEX system would not be quite so simple.  In
the first place, TENEX doesn't exist for our projected hardware
configuration, and in the second place, we have been told we cannot
put our display or real time stuff in TENEX
and have it become part of the regular
system; we would have to modify each new version of TENEX or else
run a programming race with the TENEX group or else start to deviate
from TENEX.
Without extensive modifications to TENEX, this would involve giving up
our display oriented time-sharing and going to a system in which the
displays imitated teletypes.  There would also be considerable complexities
involved in handling our real time devices such as the arms and the TV
cameras.  These would almost certainly require extensive mods to TENEX.
There is the  further problem that the KL-10 has yet a different paging
system from the KI-10 or the BBN box.  The advantage would be absolute
compatibility with TENEX.  However, it might turn out that this is
we would lose our system programmers if a decision were made that was
totally determined by an administrative fiat for uniformity.
With major adaptations, however, TENEX could serve, but the amount of
work would be high, and there would be a strong tendency to give up
the uniformity again in order to keep display orientation.

	c. The third way is what will happen if ARPA wants to minimize costs
but still will let us accept the KL-10 and install the second 256K of memory
and keep the KA-10, which is all part of a current deal negotiated with D.E.C.
but awaiting acceptance of our request for funding for more memory.
In that case, Jeff Rubin will build the \F1mappiplexor\F0 he has almost
finished designing, and we will make a new TENEX compatible time-sharing
system.  TENEX compatible will mean that we will be able to run
TENEX programs here, and TENEX users will be able to run all programs
written here that don't depend on the display-based features of our
system.



Queries

	1. What is a display-based time-sharing system?

	2. Why isn't just plain TENEX good enough?

	3. What happened about VIROS and TENEX?

	4. What will it cost to let you go your way?

2. Uniformity and diversity in hardware and software.

	The benefits of uniform hardware and software are obvious.
However, there are certain impracticalities and disadvantages of
an overly rigorous policy in this direction.  They are the following:

	1. The projects supported don't get hardware at the same time.
The best solution now is not the best solution two years from now.

	2. A uniformity of equipment often leads to overbuying in some
installations.

3. Time-sharing research.

	Originally ARPA supported most of the time-sharing research in the
country including MULTICS, the Berkeley time-sharing work that led to
the SDS-940, the work on the Q-32 at SDC, and, perhaps unintentionally,
the work that led to the Michigan time-sharing system, and finally TENEX.
Some time ago, ARPA apparently declared itself out of that business, I
suppose declaring the time-sharing problem solved or at least in a position
to be relegated to the computer manufacturers.

	However, the problem isn't finally solved, and here are some of the
opportunities for further work.

	1.